Set completion item's text edit if optional replacement span and insert text are present #1579
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There was a problem hiding this comment.
Pull Request Overview
This PR fixes a bug where completion items with insertText were not being properly applied when an editRange was set in the completion defaults. The issue occurred because LSP clients ignore insertText when editRange is present, causing items like optional properties to show their label (e.g., name?) instead of the intended insert text (e.g., name).
- Modifies completion logic to convert
insertTexttotextEditwheneditRangeis set - Updates affected test cases to expect
textEditinstead ofinsertText - Removes one test case that's no longer relevant
Reviewed Changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| internal/ls/completions.go | Adds logic to convert insertText to textEdit when editRange is present in item defaults |
| internal/ls/completions_test.go | Removes test case for static class member completions |
| internal/fourslash/tests/manual/completionsWithDeprecatedTag4_test.go | Updates test to expect textEdit instead of insertText for optional property completion |
| internal/fourslash/tests/manual/completionsSelfDeclaring1_test.go | Updates test to expect textEdit instead of insertText for optional property completion |
| internal/fourslash/tests/manual/completionsAtIncompleteObjectLiteralProperty_test.go | Updates test to expect textEdit instead of insertText for optional property completion |
| internal/fourslash/tests/completionFilterText1_test.go | Updates multiple test cases to expect textEdit instead of insertText for private field completions |
| internal/fourslash/_scripts/manualTests.txt | Adds three test files to manual test list |
gabritto
commented
Aug 13, 2025
| }, | ||
| }, | ||
| }, | ||
| { |
There was a problem hiding this comment.
This test file will be deleted as part of the snapshopt PR, and we also have fourslash tests now, so I just deleted this test case instead of updating it.
jakebailey
approved these changes
Aug 13, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #1568.
As per my comment on the issue, the problem happens because in LSP, if an
editRangeis present in the completion response (i.e. we set a defaulteditRangeto be used for all completion items), then an item'sinsertTextis ignored. This is in line with the behavior when you specifytextEdits in individual items:insertTextis also ignored in that case.Ignoring
insertTextmeant the client would use the item's label, e.g.name?, instead of theinsertText'sname.We may get rid of this problem in the future if instead of appending
?in the item's label directly, we use the item'slabelDetails.But I want to fix the bug right away, and (1) not all clients support
labelDetails, and (2) I'd like to have snippet completions implemented before figuring out the rightlabelDetailsbehavior, because snippet completions also uselabelDetails.